На известном ресурсе vreference.com (автор - Forbes Guthrie), прославившемся тем, что публикует различные шпаргалки для VMware vSphere, которые можно повесить на стену в серверной, появилось превью документа vSphere 5 vReference Card в части управления виртуальными машинами и их конфигураций:
Серым цветом выделено то, в чем автор пока сомневается. В документе есть также описания различных технологий VMware - как новых, так и старых. В ближайшее время ожидается релиз полной версии vSphere 5 vReference card.
Многим из вас, уважаемые читатели, известна компания Softline, которая как и мы занимается продвижением технологий виртуализации. А технологии эти, как вы знаете, очень и очень разнообразны. В каких-то сферах - это лучший наш конкурент :), а в каких-то - один из лучших партнеров (назовем это одним из видов coopetition).
Сразу хотим анонсировать бесплатный вебинар компании Softline - "VSPP – программа аренды лицензий VMware", который пройдет 30 ноября 2011 г. в 10.00 по московскому времени:
В рамках вебинара будут рассмотрены следующие темы:
Почему аренда?
Что такое VMware Service Provider Program (VSPP)?
Кому нужна данная программа? – Как работает VSPP?
Детали. Особенности. Требования.
Компания Softline обладает статусом VSPP Aggregator, что позволяет заключать контракты с поставщиками услуг на лицензирование по программе VSPP.
Softline стала первой российской компанией-обладателем статуса VSPP Aggregator по программе VMware Service Provider Program. Этот статус позволяет Softline предлагать своим партнерам ПО VMware в аренду на основе ежемесячных платежей.
Кратко, что есть агрегатор. Программа VMware VSPP - это отдельная ветка партнерства с VMware, предназначенная для компаний, который хотят сдавать в аренду виртуальные машины или другие объекты инфраструктуры VMware сторонним организациям и пользователям на основе регулярной (например, помесячной) платы за использование некоторым объемом ресурсов. Суть в том, что по лицензионному соглашению VMware вы не можете сдавать виртуальные машины (или другие объекты) в аренду без статуса VSPP.
А те, кто в этом статусе нуждаются - это телеком-операторы, интернет-провайдеры, системные интеграторы поставщики SaaS и другие компании, которые ведут бизнес по модели для клиентов "Pay-as-you-go". Чтобы вести такой бизнес (сдавать виртуальные машины или виртуальные ПК в аренду) надо стать партнером VMware по программе VSPP.
Но если, например, в случае с перепродажей лицензий вам нужен дистрибьютор, то в случае со сдачей виртуальных машин в аренду ваша компания также должна иметь "облачного" дистрибьютора, обладающим статусом VSPP Aggregator, с которым вы будете рассчитываться за аренду лицензий. На данный момент (по сведениям Partner Locator) компания Softline является единственным агрегатором VSPP в России, поэтому за дополнительными сведениями обращайтесь по этой ссылке.
Если вы читали VMware Security Hardening Guide в последней редакции, то, должно быть, знаете, что в целях безопасности операции Copy и Paste в консоли виртуальных машин отключены по умолчанию.
Та же самая ситуация и с клиентом VMware View Client - по умолчанию пользователи не могут ничего скопировать в свою клиентскую ОС, хотя это часто нужно. Эту ситуацию можно исправить, изменив шаблон групповой политики pcoip.adm, который находится в следующей папке на VMware View Connection Server:
Кроме того, напомним, что шаблон pcoip.adm содержит еще несколько интересных параметров, касающихся производительности отображения рабочего стола пользователя, о которых написано у нас тут.
Компания Apple известна своей старческой позицией по отношению к лицензионным условиям для запуска своих операционных систем в виртуальных машинах. В частности, только сравнительно недавно компания позволила запускать серверные версии своих операционных систем Mac OS в виртуальных машинах (OS X Lion обычный и Server, OS X Snow Leopard Server и OS X Leopard Server).
А вот клиентские версии Leopard (10.5) и Snow Leopard (10.6) запускать нельзя (для OS X 10.7 Lion это ограничение было снято). Недавно компания VMware выпустила минорное обновление продукта для виртуализации настольных ПК VMware Fusion 4.1, который имеет следующие новые возможности:
Функция Smart Full Screen, позволяющая удобно работать в полноэкранном режиме
Функция Automatic Virtual Machine power on
Улучшенная анимация
Ускорение изменение рабочей области экрана и уменьшенное время загрузки
Улучшенная поддержка гостевых Mac OS X Lion и Leopard
Улучшенная производительность графики
Но инженеры VMware "забыли" вставить в мастер установки виртуальной машины строгую проверялку того, что устанавливается серверная Mac OS X (а раньше не забывали). То есть, установщик вас просит всего лишь уважать лицензионные требования Apple и идет дальше.
Таким образом, стала возможна установка клиентских версий ОС Snow Leopard (Mac OS X 10.6) и Leopard (Mac OS X 10.5) в виртуальной машине. То-то обрадовались разработчики - теперь можно тестировать свои приложения в разных версиях ОС (особенно, учитывая, что Lion не имеет поддержки Rosetta и кода PPC), не имея под рукой нескольких компьютеров и не прибегая ко всяким ухищрениям (в принципе-то, есть конечно способы все это запускать).
Однако Apple, наверное, такой шаг восприняла без энтузиазма и, видимо, наругала VMware. Поэтому VMware сказала, что следующий апдейт уже выйдет без вот такой интересной недокументированной возможности. А пока можно пользоваться:)
И да, OS X Lion можно устанавливать в виртуальной машине, включая клиентскую и серверную версии, но только на железе Apple. Запуск Mac OS на обычном ПК по прежнему запрещен лицензионным соглашением.
Часто бывает, что от хоста ESX/ESXi нужно отвязать Datastore и LUN, на котором это виртуальное хранилище находится. При этом важно избежать ситуации All Paths Down (APD) - когда на хосте все еще остались пути к устройству, а самого устройства ему больше не презентовано. В этом случае хост ESX/ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути.
В этом случае из-за APD хоста начнут возникать задержки других задач (поскольку таймауты большие), что может привести к различным негативным эффектам вплоть до отключения хоста от vCenter.
ESX/ESXi 4.1
В версии ESX/ESXi 4.1 демон hostd проверяет том VMFS на доступность прежде чем слать туда команды ввода-вывода (I/Os) Но это не помогает для тех I/O, которые находятся в процессе в то время, когда случилась ситуация APD.
Как описано в KB 1015084, правильно отвязывать LUN с хоста ESX/ESXi 4.1 так (все делается на каждом из хостов):
Разрегистрировать все объекты с этого Datastore (если они там есть), включая шаблоны - правой кнопкой по объекту, Remove from Inventory.
Убедиться, что этот datastore не используют сторонние программы.
Убедиться, что никакие из фичей vSphere для хранилищ (например, Storage I/O Control) больше не используются для этого устройства.
Замаскировать LUN на хосте ESX/ESXi, следуя инструкциям KB 1009449 через модуль PSA (Pluggable Storage Architecture).
Со стороны дискового массива распрезентовать LUN от хоста.
Сделать "Rescan for Datastores" на хосте ESX/ESXi.
Удалить правила маскирования LUN, которые вы сделали на шаге 4 по инструкции в KB1015084.
Убедиться, что не осталось путей к устройству, после того, как вы проделали все эти операции.
Для ESX/ESXi 4.1 процесс достаточно сложный, теперь давайте посмотрим, как это выглядит в ESXi 5.
ESXi 5.0
В ESXi 5.0 появился новый статус Permanent Device Loss (PDL), то есть когда хост считает, что дисковое устройство уже никогда не будет снова подключено, а ситуация APD рассматривается как временный сбой, после которого хост снова увидит пути и устройство.
Чтобы избавиться от сложной процедуры отключения LUN от хостов ESXi, VMware сделала операции detach и unmount в интерфейсе vSphere Client и в командном интерфейсе CLI.
Вот тут можно найти unmount Datastore (но устройство продолжит быть доступным):
А вот тут находится detach для самого устройства:
Как описано в KB 2004605, чтобы у вас не возникло ситуации APD, нужно всего-лишь сделать detach устройства от хоста. Это размонтирует VMFS-том (если там есть какие-нибудь объекты - vSphere Client вам сообщит об этом).
Таким образом правильная последовательность отключения LUN в ESXi 5.0 теперь такова:
Разрегистрировать все объекты с этого Datastore (если они там есть), включая шаблоны - правой кнопкой по объекту, Remove from Inventory.
Убедиться, что этот datastore не используют сторонние программы.
Убедиться, что никакие из фичей vSphere для хранилищ (например, Storage I/O Control или Storage DRS) больше не используются для этого устройства.
Сделать detach устройства на хосте ESXi, что также автоматически повлечет за собой операцию unmount.
Со стороны дискового массива распрезентовать LUN от хоста.
Сделать "Rescan for Datastores" на хосте ESXi.
Ну и в качестве дополнительного материала можно почитать вот эти статьи:
Компания VMware объявила о выходе обновленной версии VMware ThinApp 4.7, среди новых улучшений которой, самой важной, несомненно, является интеграция с сервисом VMware Horizon (текущая версия сервиса - 1.2).
VMware Horizon Application Manager позволяет ИТ-администраторам следующие службы интеграции с VMware ThinApp:
Динамическое назначение пользователей и групп виртуализованным пакетам ThinApp за счет интеграции с Active Directory.
Безопасная сквозная аутентификация (single sign-on) к унифицированному каталогу виртуализовнных приложений Windows (SaaS для пользователей вашего предприятия), а также присоединенным веб-приложениям сторонних разработчиков.
Интерфейс для самостоятельного развертывания пакетов ThinApp и назначения их пользователям.
Мониторинг и отчетность по использованию приложений и возникающим проблемам.
Как можно догадаться из картинки, VMware Horizon - это веб-сервис компании VMware, предоставляющий услуги "федерации" приложений предприятия на пользовательском портале, к которому они обращаются из вашей организации (при этом сами пакеты хранятся в репозитории ThinApp на файловой шаре внутри вашей инфраструктуры).
В такой структуре распространения виртуальных приложений предприятия можно выделить следующие компоненты:
Horizon Service - это службы компании VMware на ее стороне, предоставляющие услуги федерации, контроля прав доступа пользователей и развертывания приложений. Реализован в виде портала пользователей (с функциями самообслуживания, т.е. самостоятельного развертывания приложений) и портала администратора (управление SaaS-средой).
Horizon Connector - это виртуальный модуль (Virtual Appliance), который обеспечивает взаимодействие среды VMware Horizon с компонентами вашей инфраструктуры.
Active Directory (your own) - то, откуда берутся списки пользователей и групп.
ThinApp Repository - обычный SMB-ресурс (шара), где находятся виртуализованные пакеты ThinApp
Horizon Agent - это агент на виртуальном ПК, который контролирует виртуализованные приложения.
После развертывания агента, Horizon Application Manager выводит иконки приложений на "Start Bar", двойной клик на которые позволяет запустить виртуализованное приложение, хранящееся в репозитории (или внешнее веб-приложение).
То есть, собственно, "федерация" - это и есть объединение виртуализованных пакетов ThinApp и сторонних сервисов для пользователей вашего предприятия, чтобы предоставить им SaaS-платформу для самостоятельного развертывания приложений. И VMware ThinApp 4.7 - это первый релиз, поддерживающий функционал VMware Horizon.
Решил перевести новость о том, что OpenShift теперь объединяет Jenkins, JBoss Tools и Maven, позволяя Java-разработчикам программировать, собирать, развёртывать и масштабировать приложение в облаке.
Red Hat предлагает вам использовать OpenShift не только для хостинга приложений, но и для всего цикла разработки ПО. Вы можете программировать, компилировать и улучшать своё ПО прямо в «облаке», не используя для этого десктоп или мощный ноутбук.
Новые возможности Red Hat Enterprise Virtualization 3.0:
Средство управления Red Hat Enterprise Virtualization Manager теперь построен на базе Java, запущенной на платформе JBoss (ранее использовался .NET, и, соответственно, была привязка к Windows, теперь же можно использовать Linux для управляющего сервера).
Портал самообслуживания пользователей, позволяющий им самостоятельно развертывать виртуальные машины, создавать шаблоны и администрировать собственные окружения.
Новый API, позволяющиий получить доступ ко всем компонентам решения из сторонних приложений.
Расширенный механизм администрирования, предоставляющий возможность гранулированного назначения пермиссий, делегирования полномочий на базе ролей пользователей и иерархическое управление привилегиями.
Новые возможности по работе с локальными хранилищами (но для них не поддерживается Live Migration).
Интегрированный механизм отчетности, позволяющий анализировать исторические данные о производительности и строить прогнозы по развитию виртуальной инфраструктуры.
Оптимизация протокола SPICE для WAN-соединений, включая технологии dynamic compression и автоматической настройки эффектов рабочего стола и глубины цветности. Кроме того, новая версия SPICE имеет расширенную поддержку десктопов Linux.
Обновленный гипервизор KVM на основе последнего Red Hat Enterprise Linux 6.1, вышедшего в мае 2011 года.
Поддержка до 160 логических CPU и 2 ТБ памяти для хост-серверов, 64 vCPU и 512 ГБ памяти - для виртуальных машин.
Новые возможности по администрированию больших инсталляций RHEV 3.0.
Поддержка больших страниц памяти (Transparant Huge Pages, 2 МБ вместо 4 КБ) в гостевых ОС, что увеличивает производительность за счет меньшего количества чтений.
Паравиртуализованный контроллер x2paic, который уменьшает overhead на содержание ВМ.
Технология Async-IO для оптимизации ввода-вывода.
Скачать Red Hat Enterprise Virtualization 3.0 Beta можно по этой ссылке.
Компания Citrix в конце октября выпустила новую версию своего клиента для мобильных устройств и планшетов Citrix Receiver for iPad and iPhone 5.0 (мы как-то пропустили эту новость), позволяющего получить доступ к виртуальным ПК Citrix XenDesktop и виртуальным приложениям Citrix XenApp.
Напомним, что клиент доступен не только для iPhone и iPad, но и для устройств на платформах Mac, Windows, Android and BlackBerry.
Новые возможности Citrix Receiver for iPad и iPhone 5.0:
Поддержка iOS 5
Поддержка Universal iOS Applications
Улучшения технологии HDX (отображение графического интерфейса и качества обслуживания пользователей)
На 40% меньше требования к пропускной способности канала
Увеличение времени запуска приложения на 50%
Поддержка продукта XenApp Fundamentals 6 (самое дешевое издание)
Поддержка механизма Session Sharing и средства управления Connection Center
Упрощенный пользовательский интерфейс
Поддержка высоких разрешений гостевых (до 1600 x 1200)
Улучшенный и оптимизированный механизм управления сессиями
Улучшенная поддержка внешней клавиатуры
Улучшенная поддержка iOS gestures
Улучшения auto-discovery
Улучшенная поддержка продукта Citrix Access Gateway Support
Улучшения стабильности и безопасности клиента
Список всех возможностей клиента Citrix Receiver for iPad и iPhone 5.0.1 доступен тут.
Как вы знаете есть самое лучшее средство для создания отказоустойчивых хранилищ iSCSI - StarWind Enterprise HA. С его помощью можно, используя всего 2 физических сервера, создать недорогое хранилище для виртуальных машин (в том числе на базе локальных дисков серверов) с поддержкой возможностей HA/vMotion/SVMotion и т.п., которое переживет отказ одного из узлов без простоя виртуальных машин. Кроме того, есть отдельная версия продукта для создания отказоустойчивого хранилища и кластера ВМ на базе всего двух серверов - StarWind Native SAN for Hyper-V.
Пользователи StarWind часто спрашивают, а как можно создать резервную копию конфигурации самого сервера StarWind? Ведь если у вас много хранилищ (например, вы их цепляете с дискового массива), то в случае переустановки Windows или сбоя сервера их восстановление может занять значительное время.
Выход прост и элегантен - нужно просто бэкапить/восстанавливать файл starwind.cfg и убедиться в том, что буквы дисков (где лежат ima-файлы хранилищ) остались теми самыми, что и раньше, после переустановки или восстановления ОС. Все это применимо и к StarWind Enterprise HA для обоих узлов HA. Таким же образом можно организовать и переезд одного из узлов StarWind на другой сервер.
Компания Oracle объявила о выходе своей операционной системы Oracle Solaris 11, доставшейся ей после поглощения корпорации Sun Microsystems. На выпуск новой версии ушло почти 7 лет - прошлый релиз вышел в январе 2005 года (не считая Solaris 11 Express).
Как знают многие Enterprise-администраторы, в Solaris есть технология виртуализации Solaris Containers, которая представляет собой подвид виртуализации уровня операционной системы (она же Solaris Zones). Зоны работают как полностью изолированные виртуальные серверы внутри одного экземпляра операционной системы.
Надо отметить, что Oracle поддерживает запуск Solaris в качестве виртуальной машины на Oracle VM Server для платформ x86 и SPARC.
Новые возможности Solaris 11, касающиеся виртуализации:
Поддержка Oracle Solaris 10 Zones, включая исполнение окружений Solaris 10 в зоне Solaris 11
Средства оценки миграции зон (P2V и V2V) с указаниями возможных проблем
Поддержка NFS в неглобальной (обычной, non-global) зоне
По умолчанию каждой зоне выделяется отдельный IP-стек (Exclusive-IP Zones)
Автоматическое создание интерфейсов VNIC для зон
Возможности настройки полосы пропускания и QoS для трафика из обычных зон
Делегирование полномочий по администрированию через Role Based Access Control (RBAC)
Окружения Zone Boot Environments интегрированные Oracle Solaris Zones. Когда создается новое загрузочное окружение (путем клонирования существующей зоны), базовое окружение также клонируется в новое boot environment
Улучшения Zone Dataset Layout
Immutable Zones с поддержкой файловых систем read-only для обычных зон за счет использования механизма Mandatory Write Access Control (MWAC)
Zoneadm теперь может корректно завершать работу зон
Zonestat теперь более эффективно работает в зонах (мониторинг ресурсов)
Библиотека Libzonestat для использования сторонними приложениями
Полный список новых возможностей Solaris 11 приведен в этом документе.
Update. Oracle утверджает, что Solaris 11 - это первая "облачная" ОС. С этим трудно согласиться.
Хочу поддержать коллег (в частности, Костю Введенского из StarWind) и сообщить нашим друзьям с Украины, что 25 ноября в Киеве пройдет первая НА Украине встреча VMware User Group.
Что это такое? Это неофициальное мероприятие, посвящённое любым техническим темам, которые касаются компании VMware и её продуктов. Встречи такого формата проходят во многих городах и странах мира.
Для чего это нужно? Встреча может помочь всем желающим поделиться своим опытом с коллегами, узнать что-то новое и в неформальной обстановке пообщаться с высококлассными специалистами и представителями самой VMware, а также других профильных вендоров.
Для кого это всё? Большая часть обсуждений на мероприятиях такого рода зачастую носит технический характер (презентация решений, всевозможные howto и технические сравнения продуктов) – потому встреча в первую очередь нацелена на администраторов виртуальных инфраструктур, инженеров поддержки, системных администраторов и различных IT-специалистов, интересующихся тематикой виртуализации. Кроме того, обзорные доклады, релизы новейших продуктов и секретные подробности ещё не выпущенных продуктов могут заинтересовать руководителей IT-отделов, IT-аналитиков и просто энтузиастов от IT, жалающих быть на гребне новых тенденций.
И сколько? Нисколько. По традиции, участие в данном меропрятии бесплатное.
Дата: 25 ноября Место: конференц зал Арена Плаза. Количество мест строго ограничено. Зарегистрироваться можно по этой ссылке.
Как многие знают, у компании VMware есть продукт VMware ThinApp, который позволяет создавать виртуализованные приложения, "отвязанные" от операционной системы (многие еще помнят этот продукт как Thinstall, а приложения так и назывались thinstalled applications). Такие приложения еще называют предустановленными - в результате его создания вы получаете 1 или 2 файла, которые можно просто переносить на флэшке и запускать или запускать с общего SMB-ресурса (см. нашу заметку тут).
Кроме того, виртуализацию приложений ThinApp можно интегрировать с решением для создания инфраструктуры виртуальных ПК предприятия VMware View 5 (см. нашу заметку тут). А скоро их вообще можно будет запускать через веб-браузер с поддержкой HTML5 в рамках решения VMware AppBlast (см. тут), извлекать из рабочих машин и распространять через ThinApp Factory (см. тут).
В этой заметке мы рассмотрим, какие режимы функционирования виртуализованных приложений ThinApp, а точнее - режимы изоляции приложения, определяющие с какими данными оно может работать и как взаимодействует с ОС, в которой запускается. Это определяет степень отделения приложения от ОС, в которой оно работает. Отделение это реализовано за счет папок и веток реестра "песочницы" (sandbox) приложения - определение того, куда приложение может производить запись и как влиять на файлы ОС.
В файле package.ini, который идет в составе проекта вы можете детально определить, в какие папки и ветки реестра приложение может осуществлять запись.
Всего есть 3 режима приложений ThinApp:
Full - в этом режиме приложение работает с реестром и файловой системе в условиях полной изоляции. Все элементы (изменения реестра и создаваемые файлы) остаются только внутри песочницы, а приложение не может ничего получить из ОС, ее файловой системы и реестра. То есть, приложение никак не повлияет на работу ОС и ничего не сможет в ней ни прочитать, ни изменить, ни создать. Файлы из песочницы и создаваемые объекты реестра существуют в виртуальных контейнерах только во время работы приложения, как только вы его закрываете - все пропадает.
WriteCopy - в этом режиме приложение может читать файлы ОС, в которой исполняется, но не может ничего записывать.
Merged - в этом режиме приложение может и читать, и записывать свои файлы, что необходимо для "тяжелых" пользовательских приложений (например, Microsoft Office).
При создании виртуализованного приложения в ThinApp в Setup Capture wizard, вы можете создавать только следующие режимы изоляции:
Modified Merged isolation mode - возможность чтения-записи файлов, кроме системных директорий.
Modified WriteCopy isolation mode - возможность ограниченного чтения файло ОС.
В режиме Modified Merged isolation mode приложению нельзя записывать ничего в следующие папки:
%AppData%
%Local AppData%
%Common AppData%
%SystemRoot%
%SystemSystem% (*see note below)
%ProgramFilesDir%
%Program Files Common%
В режиме Modified WriteCopy isolation mode приложению можно записывать только в следующие папки:
%Desktop%
%Personal% (My Documents)
%SystemSystem%\spool
GUI ThinApp позволяет задавать только эти 2 режима изоляции и только для файловой системы, остальные режимы изоляции и режим работы с реестром задается в файле Package.ini проекта ThinApp. По умолчанию режим RegistryIsolationMode в этом файле установлен в WriteCopy.
Помимо режимов работы для всей файловой системы и реестра, вы можете создать исключения для отдельных директорий и веток реестра с помощью файла ##Attributes.ini (как это делается описано тут).
Ну и на видео ниже вы можете услышать детальное описание режимов работы изоляции приложений ThinApp:
Кстати, хинт - для разработки пакетов ThinApp есть удобный редактор ThinApp Browser.
Среди подобных новостей о покупке Gluster очень много общих слов и очень мало анализа того, зачем Red Hat сделала эту покупку и как она может отразиться на рынке облачных вычислений. Пришлось думать самому. :-) Я собрал информацию из различных источников и надеюсь, что смогу немного прояснить ситуацию.
Некоторые из вас, конечно же, как-то раз задумывались - а не открыть ли мне свой бизнес по сдаче в аренду виртуальных машин VMware vSphere? У каждого клиента будут свои виртуальные машины, я буду собирать с них помесячно плату, они уже никуда не соскочат, а мне останется лишь собирать деньги, да знай себе поддерживать инфраструктуру и наращивать мощности.
Я как человек в этом немного покрутившийся, могу вам сказать, что здесь не все так просто, и сам бы я такой бизнес профильным не сделал бы ни за что на свете. Но для тех, кого все-таки не оставляет эта идея, ниже приведены некоторые моменты об организации облака на основе решений VMware, виртуальные машины из которого вы можете предоставлять как услугу.
Начнем с того, что обычные лицензии VMware, которые вы покупаете у одного из партнеров или получаете как Internal Use Licenses, не позволяют вам сдавать виртуальные машины в аренду (внешним пользователям, не в своей организации) - это прямо запрещено пользовательским соглашением (EULA). Поэтому для таких дельцов придумана программа VSPP - VMware Service Provider Program (за само партнерство в программе платить не надо).
Программа VSPP направлена для сервис-провайдеров, телеком-операторов, интернет-провайдеров, поставщиков услуг, системных интеграторов и ИТ-подразделений корпораций, которые "продают" ИТ-ресурсы дочерним или аффилированным компаниям.
Эта программа позволяет вам получить некоторый пакет продуктов в рамках вашего партнерства с VMware по программе VSPP и начать предоставлять пользователям виртуальные машины (но не только!) в аренду, используя множество программных продуктов: vSphere, vCloud Director, vShield, View и многое другое. Всего есть несколько уровней партнерства по VSPP, у каждого из которых есть свои преимущества и требования.
Здесь нужно выделить 2 ключевых момента - это очки (points) и Aggregator (агрегатор) VSPP. Начнем с агрегатора. На самом деле вы не можете подписать контракт с VMware и начать сдавать в аренду ее машины и отчислять ей платежи. Это потому, что VMware ведет бизнес в каждой стране по своему и там ей нужны партнеры, которые посредством своих мутных схем и офшоров будут гонять бабло между, например, Россией, Кипром, ОАЭ и Америкой с одной стороны, а с другой - между юрлицом в России и российскими партнерами VMware.
Собственно, агрегатор - это тот же дистрибьютор, только касаемо облачных сервисов VMware. Но у него есть и некая техническая функция. Когда вы вписываетесь в VSPP, у вас в инфраструктуре vSphere развертывается специальное ПО на сервере vCenter, котороя смотрит сколько расходуется у вас ресурсов для виртуальных машин и посылает эти данные агрегатору. Делается это ежемесячно.
Далее агрегатор посылает эти данные в VMware на аудит, а сам выставляет вам счет, чтобы собрать бабло, которое дальше через офшоры и серые схемы потечет в VMware. В России таких агрегаторов несколько, и вы их найдете без труда.
Далее ключевой момент это очки (points), которые вы покупаете (а точнее, арендуете) ежемесячно, чтобы иметь право предоставлять некоторое количество услуг на базе продуктов VMware (чаще - виртуальных машин) в аренду. Самое важное тут то, что в большинстве случаев единицей тарификации является сконфигурированная оперативная память виртуальных машин (vRAM) - очки за 1 ГБ. Но есть и другие варианты тарификации для некоторых продуктов:
Но вас, скорее всего, интересует только Infrastructure as a Service (IaaS) - то есть, собственно, сдача виртуальных машин в аренду (то, что выделено красным). На сами цифры не смотрите - они американские и для нас неактуальные.
Для нас интересны вот эти 2 набора (эти цифры, вроде, актуальные):
VSPP Standard Bundle - это, по-сути, VMware vSphere 5 + Chargeback (для внутреннего биллинга) + vCloud Director (система управления датацентром с точки зрения облака - выделение ВМ и ресурсов, задание уровней сервиса, управление пользователями и т.п.). Для нас он стоит 5 очков в месяц за 1 ГБ памяти виртуальных машин (ниже я расскажу какой гигабайт). Второй VSPP Enterprise Bundle включает в себя еще и продукт vShield Edge для комплексной защиты периметра датацентра (см. подробнее тут и тут).
Теперь о тарификации этого самого гигабайта. Вы уже поняли, что единица стоимости - это 1 point, сколько он стоит в России я вам не скажу, но скажу, что в Америке 1 point = 1$. А суть лицензирования гигабайта такова:
Вы создаете виртуальные машины для аренды и выставляете им vRAM Reservation, но не менее 50% (требование VMware) от сконфигурированной памяти.
Максимально учитывается на одну ВМ - не более 24 ГБ.
Умножаете ваш бандл (например, для Standard - это 5 очков) на число vRAM ваших ВМ и на долю зарезервированных ресурсов (например, для 50% это, понятное дело, 0,5). Получаете общее количество очков в месяц, за которые вам надо платить агрегатору.
Выключенные ВМ не тарифицируются.
Как видно, у сервис-провайдера VSPP тоже есть некоторые права - вы можете гарантировать меньше ресурсов и меньше платить, либо обеспечить 100%-й SLA, но платить больше.
Смотрим на пример расчета:
Ну и каждый месяц агрегатор смотрит, сколько у вас набежало использованных очков, способствует продвижению уровня партнерства VSPP и выбиванию скидок за объем потребляемых поинтов. Вот тут есть хороший FAQ по программе VSPP, а тут - презентация.
Вкратце - это все. Тема у нас пока эта очень муторная. Если инетересно дальше - могу дать контакт с кем можно поговорить на эту тему. Ну а хотите купить виртуальные машины VMware в аренду - пожалуйста.
Несмотря на то, что в VMware vSphere Client диски виртуальных машин создаются уже выровненными относительно блоков системы хранения данных, многих пользователей платформы беспокоит, не выглядит ли их дисковая подсистема для ВМ таким образом:
Специально для таких пользователей, на сайте nickapedia.com появилась бесплатная утилита UBERAlign, которая позволяет найти виртуальные диски машин с невыровненными блоками и выровнять их по любому смещению.
Но самое интересное, что утилита UBERAlign работает еще и как средство, позволяющее уменьшать размер виртуальных дисков ВМ с "тонкими" дисками (thin provisioning), возвращая дисковое пространство за счет удаленных, но не вычищенных блоков.
Скачать UBERAlign можно по этой ссылке (а вот тут в формате виртуального модуля OVA), полный список возможностей утилиты можно найти тут (там еще несколько видеодемонстраций).
Как вы знаете, компания Код Безопасности, выпускающая продукт номер 1 для защиты виртуальных сред vGate R2 (читаем тут и тут), выпускает еще несколько программных и аппаратных решений для защиты физической и виртуальной инфраструктуры (см., например, тут).
Один из таких продуктов, интересных вам - это Security Code TrustAccess, который позволяет организовать распределенный межсетевой экран (МЭ) с централизованным управлением, предназначенный для защиты серверов и рабочих станций локальной сети от несанкционированного доступа и разграничения сетевого доступа к информационным системам предприятия, в том числе в инфраструктурах виртуализации (а также трафика между машинами в рамках одного хост-сервера).
Надо сказать, что TrustAccess - это один из тех продуктов, которые позволят защитить виртуальную инфраструктуру vSphere, в которой обрабатываются персональные данные, согласно требованиям закона ФЗ 152. То есть его можно и нужно использовать совместно с продуктом vGate.
Многие пользователи VMware vSphere знают, что для кластера HA раньше была настройка das.failuredetectiontime - значение в миллисекундах, которое отражает время, через которое VMware HA признает хост изолированным, если он не получает хартбитов (heartbeats) от других хостов и isolation address недоступен. После этого времени срабатывает действие isolation response, которое выставляется в параметрах кластера в целом, либо для конкретной виртуальной машины.
В VMware vSphere 5, в связи с тем, что алгоритм HA был полностью переписан, настройка das.failuredetectiontime для кластера больше не акутальна.
Теперь все работает следующим образом.
Наступление изоляции хост-сервера ESXi, не являющегося Master (т.е. Slave):
Время T0 – обнаружение изоляции хоста (slave).
T0+10 сек – Slave переходит в состояние "election state" (выбирает "сам себя").
T0+25 сек – Slave сам себя назначает мастером.
T0+25 сек – Slave пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
T0+30 сек – Slave объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.
Наступление изоляции хост-сервера ESXi, являющегося Master:
T0 – обнаружение изоляции хоста (master).
T0 – Master пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
T0+5 сек – Master объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.
Как мы видим, алгоритм для мастера несколько другой, чтобы при его изоляции остальные хосты ESXi смогли быстрее начать выборы и выбрать нового мастера. После падения мастера, новый выбранный мастер управляет операциями по восстановлению ВМ изолированного хоста. Если упал Slave - то, понятное дело, восстановлением его ВМ управляет старый мастер. Помним, да, что машины будут восстанавливаться, только если в Isolation Responce стоит Shutdown или Power Off, чтобы хост мог их погасить.
Как мы уже писали, недавно компания StarWind выпустила решение StarWind Native SAN for Hyper-V (возможности см. тут), которое позволяет построить кластер отказоустойчивости серверов и хранилищ для виртуальных машин Hyper-V, используя всего лишь 2 физических сервера, что вдвое сокращает затраты на внедрение решения и его обслуживание.
10 ноября компания StarWind проводит вебинар по продукту Native SAN for Hyper-V, ведет его Анатолий Вильчинский, который, как не трудно догадаться, говорит по-русски, поэтому вы сможете задать все интересующие вас вопросы по решению для вашей виртуальной инфраструктуры Hyper-V.
Дана и время вебинара: 10 ноября в 19-00 по московскому времени.
Компания Veeam Software обновила результаты своего исследования по виртуализации V-Index за третий квартал 2011 года на сайте проекта. Интересен тот факт, что процент используемых виртуальных машин по сравнению с физическими стал несколько меньше:
Кстати, консерватизм англичан проявляется и здесь. Напомним, что данные V-Index регулярно обновляются в соответствии с исследованием более 500 крупных компаний по всему миру (в исследовании за 3-й квартал приняли участи 578 компаний, за 2-й - 544 организации). А еще у V-Index есть замечательная инфографика:
Полный отчет за третий квартал 2011 года читайте тут. В виде PDF можно загрузить по этой ссылке.
Интересный момент обнаружился на блогах компании VMware. Оказывается, если вы используете в кластере VMware HA разные версии платформы VMware ESXi (например, 4.1 и 5.0), то при включенной технологии Storage DRS (выравнивание нагрузки на хранилища), вы можете повредить виртуальный диск вашей ВМ, что приведет к его полной утере.
In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.
По русски это выглядит так:
Если вы широко используете Storage vMotion или у вас включен Storage DRS, то лучше не использовать кластер VMware HA. Так как при падении хост-сервера ESXi, HA может перезапустить его виртуальные машины на хостах ESXi с другой версией (а точнее, с версией ниже 5.0, например, 4.1). А в это время хост ESXi 5.0 начнет Storage vMotion, соответственно, во время накатывания последовательности различий vmdk (см. как работает Storage vMotion) машина возьмет и запустится - и это приведет к порче диска vmdk.
Надо отметить, что такая ситуация, когда у вас в кластере используется только ESXi 5.0 и выше - произойти не может. Для таких ситуаций HA и Storage vMotion полностью совместимы.
Многие задаются вопросом - а как себя поведет кластер VMware HA в vSphere 5 при отключении всех хост-серверов VMware ESXi 5 (например, отключение электричества в датацентре)?
Алгоритм в этом случае таков:
1. Все хосты выключаются, виртуальные машины на них помечаются как выключенные некорректно.
2. Вы включаете все хосты при появлении питания.
3. Между хостами ESXi происходят выборы Master (см. статью про HA).
4. Master читает список защищенных HA виртуальных машин.
5. Master инициирует запуск виртуальных машин на хостах-членах кластера HA.
Надо отметить, что восстановлении VMware HA смотрит на то, какие из них были выключены некорректно (в случае аварии), и для таких ВМ инициирует их запуск. Виртуальные машины выключенные корректно (например, со стороны администратора) запущены в этом случае не будут, как и положено.
Отличия от четвертой версии vSphere здесь в том, что вам не надо первыми включать Primary-узлы HA (для ускорения восстановления), поскольку в vSphere 5 таких узлов больше нет. Теперь просто можете включать серверы в произвольном порядке.
Многие из вас знают, что у компании VMware есть утилита VMmark, которая позволяет измерять производительность различных аппаратных платформ (и работающих в ВМ приложений), когда на них работает платформа виртуализации VMware vSphere. При этом можно сравнивать различные платформы между собой в плане производительности.
Сейчас компания VMware решила сделать несколько иначе: на одном и том же сервере Dell Power Edge R310 поставить vSphere 4, посчитать производительность, а потом сделать то же самое с vSphere 5 на этом же сервере. При тестировании было 4 типа нагрузки с нарастанием до насыщения утилизации сервера по CPU и получились вот такие результаты:
В результате ESXi 5.0 обогнал ESXi 4.1 на 3-4% очкам в зависимости от нагрузки (линии же CPU - практически одинаковы). Но самое интересное, что при росте нагрузки машин на сервер ESXi 5 позволил поддерживать виртуальных машин на 33% больше, чем ESXi 4.1 при условии соблюдения требований к качеству обслуживания для виртуальных машин - правый столбик (как это оценивалось не очень понятно). При этом ESXi 5.0 позволял выполнять в два раза больше операций с инфраструктурой в кластере, чем его предшественник (см. ниже).
Также VMware померила время отклика различных приложений и вычислила их задержки (latency), а также latency для операций инфраструктуры (vMotion, Storage vMotion и VM Deploy). Вышло так (показано в нормализованном виде):
Обратите внимание, что vMotion и Storage vMotion - стали работать значительно быстрее (о том, как это было сделано - тут). Вот как раз за счет низкого latency ESXi 5 и смог обеспечить поддержку на 33% больше виртуальных машин при условии соблюдения QoS.
Продолжаем разговор о решении номер 1 для создания отказоустойчивых хранилищ StarWind Enterprise HA, которое наиболее оптимально подходит как раз для малого и среднего бизнеса, где не хочется тратить деньги на дорогостоящее хранилище и его обслуживание. Берете просто 2 сервера, на нем поднимаете виртуальные машины и там же отказоусточивое хранилище (при отказе работает без простоя ВМ). На Hyper-V делается это с помощью StarWind Native SAN for Microsoft Hyper-V, а для VMware можно сделать так на StarWind 5.7.
Второй - это статья "Кластер Hyper-V 2008 R2 на коленке", где чувак взял и поднял кластер Hyper-V R2 с Live Migration на базе iSCSI-хранилища StarWind, используя обычные ПК.
На мероприятии UK VMware User Group Julian Wood представил интересную презентацию, которая суммирует необходимые дествия и процедуры по миграции с платформы VMware vSphere 4 на vSphere 5, включая хост-серверы ESX / ESXi, vCenter (включая его компоненты), виртуальные машины, VMware Tools и тома VMFS.
Один из лучших материалов, обобщающих информацию на тему миграции на vSphere 5.
Как знают многие из вас, в инфраструктуре виртуализации VMware vSphere одна из самых частых конфигураций платформы - назначение администратора виртуальной инфраструктуры одному человеку, который потенциально может разрушить всю инфраструктуру предприятия:
Это на самом деле очень плохо, поскольку по данным исследования, проведенного аналитической службой компании «Код Безопасности» среди 100 российских организаций, наибольшую угрозу для компании представляют инсайдеры, имеющие доступ к конфиденциальной информации. Исследование показало, что наиболее актуальными ИБ-угрозами для большинства российских компаний остаются внутренние факторы. В частности, 25% опрошенных респондентов убеждены, что наибольшую опасность для компании представляет несанкционированный доступ собственных сотрудников к конфиденциальной информации компании.
Не менее интересными являются результаты опроса в части оценки принятых мер по выполнению требований Федерального закона «О персональных данных». 52% опрошенных на вопрос: «Приняты ли в Вашей организации меры по защите ПДн в связи с вступлением в силу №152-ФЗ», – ответили утвердительно. Компании, в которых проект проводится в данный момент, но пока не завершен, составляют 37% и 5% планируют проект по защите ПДн в соответствии с требованиями №152-ФЗ на следующий, 2012 год. Среди участников опроса оказалось 6% и тех, кто пока не приступал к выполнению требований №152-ФЗ.
И вот тут нужно сказать, что vGate R2 от компании "Код Безопасности" - это лучший продукт, чтобы убить перечисленных двух зайцев: разделить полномочия администратора VMware vSphere (или по крайней мере детально протоколировать его действия) с помощью продукта vGate R2 за счет введения роли администратора ИБ, а также настроить инфраструктуру защиты VMware vSphere в соответствии с нормами ФЗ 152 за счет средств автоматической конфигурации безопасности vGate R2.
Напомним, что это vGate R2 - это единственное на сегодняшний день сертифицированное средство защиты информации от несанкционированного доступа, предназначенное для обеспечения безопасности виртуальных инфраструктур на базе платформ VMware Infrastructure 3 и VMware vSphere 4, применение которого дает возможность легитимной обработки данных ограниченного доступа в виртуальной среде. Подробнее о сертификатах vGate R2 написано тут.
Запросить пробную версию vGate R2 можно по этой ссылке.
Как многие из вас знают, в новой версии решения для виртуализации настольных ПК предприятия VMware View 5 появилось множество интересных возможностей, одно из которых возможность отключения передачи картинки десктопа пользователю без потери качества (Disable build-to-lossless) для протокола PCoIP, что очень актуально для WAN-соединений.
Если сравнивать версии VMware View, то для обычного офисного ПК необходима следующая полоса пропускания канала до устройства доступа (тонкого или толстого), если он работает в виртуальной машине:
View 4.x с дефолтными настройками = 150 Kbps
View 5.x с дефолтными настройками = 60Kbps
View 5.x с опцией Disable build-to-lossless = 48Kbps
Как видно, помимо того, что в VMware View 5 существенно уменьшились требования к каналу, с отключением передачи десктопа без потери качества можно добиться снижения требований еще до 30%.
Если говорить о качестве картинки рабочего стола, то выглядит это так:
Из картинки видна, что потери весьма незначительны. Конфигурируется эта настройка через шаблон групповой политики (GPO) pcoip.adm, расположенный на сервере VMware View Connection Server в папке:
Там много интересных настроек протокола PCoIP, но нас интересует первая - Turn off Build-to-Lossless feature:
Все это можно делать и через реестр - читайте KB 1014686 или вот тут.
Вторая оптимизация - это video frame-rate, то есть частота отображения кадров для видео, а также качество передаваемой картинки. Задается она настройкой Configure PCoIP image quality levels, где есть на выбор три опции для тюнинга протокола PCoIP:
Minimum и Maximum Image Quality - по умолчанию установлено в значение 50 (диапазон - от 30 до 100). Определяет качество картинки при заданном количестве кадров (третий параметр). Minimum гарантирует качество картинки, maximum - ограничивает полосу, необходимую для десктопа. Когда канал широкий - настройка Maximum игнорируется и PCoIP работает на максимально возможном качестве картинки.
Minimum и Maximum Initial Image Quality - это качество картинки первично передаваемой на десктоп View 5. Т.е. регулируется первично передаваемый регион картинки, а изменяющиеся регионы будут уже регулироваться первой настройкой. По умолчанию установлено в значение 90 (диапазон - от 30 до 100). Minimum Image Qualityне может превышать Maximum Initial Image Quality.
Maximum Frame Rate - по умолчанию это значение равно 30 кадрам в секунду, но для большинства случаев, если установить 15 кадров, то требование к полосе для видео уменьшится до 1,7 раза, при этом гладкость картинки останется вполне приемлемой.
Третий вид оптимизации - оптимизация полосы пропускания для аудио (Configure the PCoIP session audio bandwidth limit).
Тут варианты такие:
1600 kbps - для любителей качественного звука без компрессии в виртуальном ПК
450 kbps - качественный звук с компрессией
50-450 kbps - что-то среднее между FM-радио и телефоном
Если поставить значение 100, то будет нормальный звук (не для меломанов, конечно), при этом полоса, необходимая для аудио, снижается в 5 раз!
Четвертый вид оптимизации - это оптимизация пользовательского ПК с Windows. Тут рекомендации просты:
Выставляем настройку "optimize for performance" - требования к каналу снижаются на 10%
Отключаем шрифты ClearType - получаем еще 5%
Отключаем картинку рабочего стола, скринсэйвер, Windows update, Super-fetch и Windows index - получаем тоже выигрыш в производительности
И, наконец, регулируем настройку "Configure PCoIP client image cache size policy" - это новая функция VMware View 5, позволяющая определять размер кэша для картинок, передаваемых посредством PCoIP на сторону клиента (по умолчанию - 250 МБ)
Читаем полный список оптимизации гостевых ОС Windows 7 в качестве виртуальных ПК VMware View 5.
Вкратце - это первые шаги по оптимизации PCoIP для VMware View 5. Дальше изучаем следующие материалы:
На небезызвестном ресурсе myvirtualcloud.net появилась первая версия калькулятора XenDesktop VDI Calculator, который помогает рассчитать необходимое количество хост-серверов для размещения требуемого количества виртуальных ПК с решением Citrix XenDesktop (напомним, что ранее был выпущен калькулятор для VMware View, а также для PCoIP). В качестве ПО для VDI используются версии XenDesktop 5.0 and 5.5.
На данный момент в качестве серверной платформы виртуализации пока поддерживается только VMware vSphere 5, но, надо сказать, что этот продукт в большенстве случаев и используется в качестве платформы для XenDesktop с доставкой десктопов через MCS (Machine Creation Services) для крупных инсталляций.
Основные возможности XenDesktop VDI Calculator:
Поддержка многоядерных CPU
Поддержка 32-битных разрешений в гостевой ОС виртуальных ПК
Платформа - VMware vSphere 5.0
Поддержка использования 3D-графики в ПК
Расчет выделенных десктопов и пулов
Расчет выделения CPU для ВМ
Поддержка swap-файлов ВМ на локальном хранилище
Поддержка Delivery Controller High Availability
Расчет IOPs'ов на базе типа нагрузки, уровня RAID и т.п.
Расчет overhead'а на поддержку ВМ
Поддержка VM memory reservation
Учет overhead'а на гипервизор
Учет выключенных виртуальных ПК
Учет хранилищ, в том числе для выключенных ВМ
Использовать XenDesktop VDI Calculator можно по этой ссылке.
RSS
